1. Field
The present disclosure pertains to the field of processing apparatuses and systems that process sequences of instructions or the like, as well as certain instruction sequences to program such apparatuses and/or systems. Some embodiments relate to monitoring and/or responding to conditions or events within execution resources of such processing apparatuses.
2. Description of Related Art
Various mechanisms are presently used to monitor and profile a software program activity, including instrumentation and system-level profiling. Software instrumentation is a technique that requires the modification of the software, either during compilation or while in post-compiled (“binary”) form, by inserting codes at points where a developer would like to see the progress (e.g., output, processor state, etc.) of the software.
Instrumentation may be undesirable in certain circumstances, as instrumentation typically requires a non-trivial amount of code to be added to an instrumented program, which can result in significant performance overhead when executing the instrumented program. As a result, a delay may occur between the time when an event occurs and the time that the event is actually detected and associated with a particular operation within the code. This delay may make it difficult to accurately discern the operation or operations causing the event, which makes efforts to avoid or improve the event difficult, if not impossible. Lastly, instrumentation may be undesirable if it requires the instrumented program to be recompiled before the instrumented code is executed.
As a result, managed run-time environments, such as the Microsoft® .Net™ developer environment, may not typically support instrumentation for the development of production-quality software.
Although prior art system-level profiling techniques can be used to profile and optimize software during run-time, these techniques typically require a developer to use operating system functions (e.g., application program interface, or “API”) to monitor or profile the user-level software, which may result in performance overhead. Accordingly, a user may not be able to obtain the true performance profile of a particular program and optimize his software accordingly due to the possible operating system-imposed time lag and lack of precision between when an event occurs within a processor executing his software and when an event is recorded and becomes visible through the profiling interface. Furthermore, typical system-level profiling techniques typically do not allow a developer to profile or optimize software on a per-thread basis.
Multi-threading is a technique by which processor hardware may be utilized by multiple different threads. Multi-threaded processors may switch between threads for a variety of reasons. For example, a processor may have an algorithm that automatically switches between available threads. Other processors use switch-on-event multithreading (SoEMT), whereby certain events such as a cache miss may give rise to a thread switch. Thread switching can be considered a change of control flow because the processor switches the sequence or stream which it executes.
In any case, system-level profiling techniques are typically not able to modify, profile, or optimize a particular thread or threads of a user-level program and may incur significant processing overhead, preventing a developer from optimizing user-level programs. Furthermore, prior art instrumentation techniques may not allow a developer to modify, profile, or optimize user-level programs during run-time, or may incur significant processing overhead, further exacerbating the problem of optimizing the user-level code.